Supply chain transactions such as shipping goods from a seller to a buyer typically involves several parties that may operate different management applications (e.g., Enterprise Resource Planning (ERP)). By way of example, there are multiple parties that interact throughout the lifetime of a shipment. Example parties include the seller (sometimes referred to as the shipper), the buyer, carriers (e.g., ocean carriers, rail carriers, truck carriers, air carriers, etc.), third party logistics providers (3PLS), custom brokers, consolidators, etc. The partners in a supply chain transaction typically send and receive multiple messages during the transaction (e.g., purchase orders, advanced shipping notices, milestone updates (e.g., time the good was shipped, time the good was received, etc.), etc.). Quality of the data, including timely receipt, completeness, and accuracy of the data, is important for the proper functioning of the supply chain transaction.
Traditionally, customers were required to connect with their partners, normalize the data that they provide, and manage the data quality. Typically, connecting with a partner includes agreeing on a communications protocol and format (usually Electronic Data Interchange (EDI)). As the number of partners rise, so does the complexity of connecting them all. If the systems between partners are not the same, then the data is often required to be normalized. For example, if the cargo is arriving from a particular location, normalization ensures that the location is consistently called the same thing by each partner in the transaction. Traditional approaches for normalizing data include creating mapping tables or creating additional capabilities in the sending or receiving computer system. This gets more complex as the supply chain grows and the number of partners increases.
Resources must also be dedicated to monitor the quality of the data (e.g., for accuracy, completeness, and timeliness). Current methods limit editing rights of messages to the senders of data, but the senders have limited visibility into the receiver's integration systems and its data pipeline. When an issue arises, senders often have very little logging or diagnostic information about messages' failure. In cases where there is an error in a message, traditionally only the sender can correct the error, and then must resend the message to the recipient system. In most cases, the personnel doing the resending are information technology (IT) personnel, as opposed to the business users. This process can take days or weeks, as the IT personnel may need to reconstruct the message in its original state and then queue updates to the same record after the original message. Message integration is often a multi-stage process. In a cloud-based system where messages are sent to a cloud-based managed service (e.g., a trade and logistics portal), the senders of the data have limited visibility in the multi-stage process and often cannot determine at which stage an error occurred.